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1. REAL PARTY IN INTEREST 

NCR Corporation. 

2. RELATED APPEALS AND INTERFERENCES 

None . 

3. STATUS OF CLAIMS 

Claims 1 - 6, 8, 10, 21 - 25, and 27 are pending, rejected, 
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and appealed. 

Claims 7, 9, 11 - 20, and 26 are cancelled. 

4. STATUS OF AMENDMENTS 

No Amendment -After- Final has been filed. 

5, SUMMARY OF CLAIMED SUBJECT MATTER 

The apparatus 10 of Figure 1 of the Specification is mounted 
within a car which a person drives. The person drives to an ATM, 
Automated Teller Machine, and executes a transaction using the 
device 10. 

When the person arrives at the ATM, the ATM detects the car, 
and issues an interrogation signal. The apparatus 10 responds, 
indicating its readiness. (Specification, page 7, lines 5-8.) 

The ATM downloads a series of programs to the apparatus 10, 
which generate an interface with which the person interacts. The 
programs are sent to the memory 24 in Figure 2, and are executed 
by the processor 22. (Page 7, lines 8 - 10.) 

The interface replaces the function of the interface at the 
ATM, so that the person need not leave the car. 

Mapping of Claim Elements in Independent Claims 

Parenthetical phrases, in bold typeface, are inserted into 
the following independent claims, to identify matter in the 
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Specification and Figures which supports the claim language 
adjacent said bold, parenthetical typeface. 

1. A method of conducting a transaction from within a' 
vehicle, (page 2, lines 18, 19) the method comprising the steps 
of: 

locating the vehicle adjacent a transaction terminal 
(page 2, line 20); 

transferring one or more computer programs from the 
transaction terminal to an in-car data entry facility maintained 
within the vehicle, which programs generate a user interface in 
the entry facility (page 4, lines 14 - 19) ; 

entering user instructions into the in-car data entry 
facility (page 2, line 21); and 

transmitting the user instructions locally to the 
terminal for execution by the terminal (page 2, lines 23, 24) . 

8. An in-car apparatus to be provided within a vehicle for 
user interfacing with a transaction terminal (Apparatus 10, 
Figure 1; page 2, lines 6-10 and 18, 19) , the apparatus 
comprising: 

means for interacting with a user (page 6, lines 7-14; 
Figure 1, items 12, 14, 16, 18, and 20); 

means for receiving a computer program from the 
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transaction terminal which generates an interface in 
the apparatus (Figure 2, transceiver 2 6 and memory 24; 
page 7, lines 8 - 15) ; and 

means for transmitting data locally to a transaction 
terminal situated adjacent the apparatus (Figure 2, 
local transceiver 26; page 7, lines 12 - 16) . 



21. A method, comprising: 

a) maintaining a wireless communication device within 

V 

a vehicle (page 6, lines 5 - 8) ; 

b) positioning the vehicle near an Automated Teller 
Machine, ATM (page 7, lines 1 - 4) ; 

c) establishing wireless communication between the 
wireless device and the ATM (page 7, lines 5 - 10) ; 

d) entering identification data into the wireless 
device, which data allows the ATM to verify identity of 
a user (page 7, lines 11 - 13) ; and 

e) if the ATM verifies the user, proceeding with a 
financial transaction (page 7, lines 12 - 16; page 3, 
lines 4 - 16) . 



25. A method, consisting . essentially of the steps of: 
a) maintaining a wireless communication device within 
a vehicle, said device comprising a keypad and a card 
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reader (device 10, Figure 1; page 6, lines 5, 6; Figure 
1: card reader 14, keypad 16) ; 

b) positioning the vehicle near an Automated Teller 
Machine, ATM (page 7, lines 1, 2) ; 

c) establishing wireless communication between the 
wireless device and the ATM and transferring one or 
more computer programs from the ATM to the device, 
which programs generate an interface for the user (page 
7 , lines 5 - 10) ; 

d) inserting a card into the card reader in response 
to a prompt issued by the interface (page 7, lines 11, 
12); 

e) entering a PIN into the keypad in response to a 
prompt issued by the interface (page 7, lines 12, 13) ; 

f) relaying data from the card, and the PIN, to the 
ATM (page 7, lines 12, 13); and 

g) if the card and the PIN are accepted by the ATM, 
proceeding with a financial transaction (page 7, lines 
13 - 17; page 3, lines 4 - 16) . 

6. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The rejection of claims 1 - 3, 8, 10, and 27 on grounds of 
anticipation under 35 USC § 102, based on Dickson. 

The rejection of claims 21 - 25 on grounds of obviousness 
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under 35 USC § 103, based on Dickson and DeVries . 

The rejection of claims 4 - 6 on grounds- of obviousness 
under 35 USC § 103, based on Dickson, DeVries, and Ohki . 

7 . ARGUMENT 

SUMMARY OF ARGUMENT 
Point 1 

Claim 1 recites: 

transferring . . . computer programs ... to 

[a] . . . facility maintained within the 
vehicle , 

which programs generate a user interface in 

the . . . facility. 

Appellant points out that 

"programs" are transferred and 

they "generate a user interface." 
In a Dickson reference, a terminal in a vehicle orders 
gasoline, fast food, and other things at a convenience store. 
The convenience store transfers menu-data to the terminal, such 
as the price of hamburgers. The Final Action relies on the menu- 
data as showing the claimed "programs." 

Menu-data, which states the price of hamburgers, is not a 
"program." The claimed "program" is not shown in the reference. 
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Point 2 

The Final Action admits that Dickson transfers "data, " but 
asserts that the term "program" in the claim can be extended to 
cover the "data, " on the grounds that 

. . . the data ... in Dickson instructs the 
device as to what should be displayed on the 
interface. (Final Action, page 5, third 
sentence . ) 

However, several problems exist in this assertion. 

Problem 1 

The assertion does not apply a proper definition of 
"program." One definition is "a sequence of instructions which 
runs on a microprocessor." The data in Dickson contain no 
"instructions which run on a microprocessor." 

Problem 2 

Under the Final Action's definition, a television signal is 
a "program, " because it determines what a television displays. 

But nobody thinks that a television signal is a "program." 

The Final Action's definition is erroneous. 

Numerous similar examples are given herein. ("PROBLEM 5," 
near page 27 . ) 
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Problem 3 

The assertion contradicts the claim. The assertion states 
that the "data" "instructs" the "interface." Thus, the 
"interface" is pre-existing in the vehicle. 

The claim states that the transferred "programs" "generate" 
the " interface . 11 

Problem 4 

The Final Action, page 5, states "Programs may be anything 
which instruct a computer." This is incorrect. Programs do not 
"instruct" a computer. Programs RUN on a computer, or 
microprocessor . 

Further, the phrase "instruct a computer" is non-standard, 
and lacks meaning. 

Problem 5 

The Final Action's definition of "program, " as in Problem 4, 
above, is inapplicable to the claimed subject matter. 

In Dickson, the data is transferred to a computer /program 
combination. The program accepts the data, and displays it. 

Thus, the "data" in Dickson does not actually "instruct" the 
computer. The "data" is given to a program which contains the 
instructions, and the program displays the data according to 
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those instructions . 

Again, there is no "program 11 which is "transferred" and 
which "generates" an "interface." 

Problem 6 

As explained above, the "data" in Dickson is the price of 
hamburgers, and the like. Plainly, that data is accepted by the 
program/computer combination in the vehicle, and inserted into 
the proper place in a menu which is displayed. 

Thus, at best, the data controls PART OF the display. That 
does not show the claim, which states 

transferring . . . computer programs ... to 
[a] . . . facility maintained within the 
vehicle, 

which programs generate a user interface in 
the . . . facility. 

Problem 7 

In this situation, the MPEP requires that the Final Action 
set forth the definition of "program" which is being used. That 
has not been done . 

Point 3 

Assume the Final Action is correct, and Dickson transfers a 
"program" which "instructs" Dickson's IVC on what to display. 
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The claim does not recite that. The claim recites a 
"program" which "generates an interface." 

That is, if the Final Action is correct, it has merely shown 
a "program" in Dickson, but the claim recites a different 
program. 

Point 4 

The Final Action is asserting that any input to a computer 
is a "program." The Final Action, page 5, fourth sentence, 
states "Programs may be anything which instruct a computer . . . " 

Appellant points out that a mouse delivers signals which 
"instruct" a computer. Nobody considers those signals to be a 
"program. " 

A similar comment applies to keyboard input and incoming e- 
mail messages. 

Point 5 

As explained herein, the data of Dickson can be handled 
without any involvement of a microprocessor. 

In brief: the data can be received by a DMA (Direct Memory 
Access) device, and loaded into video RAM. Then, a graphics card 
reads the data from video RAM and causes the display to present 
the data ( eg , the current price of hamburgers ) . 

The microprocessor is not involved. Thus, the data cannot 
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be a program. 

Further, this type of design saves microprocessor time, and 
allows a cheaper microprocessor to be used, because the 
microprocessor is not involved in handling the data in question. 

"Program" in Remaining Claims 

The discussion above, regarding transfer of a "program, " 
applies to the remaining claims, except claim 21. 

Claim 8 

Claim 8 contains a "means-plus -f unction" element: 

means for receiving a computer program from 
the transaction terminal which generates an 
interface in the apparatus. 

Under section 112, the subject matter in the reference 
showing this "means" must "correspond" to that in Appellant's 
Specification, or be "equivalent" thereto. 

The Specification, page 7, lines 8-10, states: 

A series of computer programs are then 
transferred from the terminal 32 to the 
memory 24 . . . , where processor 22 executes 
the programs to generate an appropriate 
interface environment for the particular 
transaction type. 

If the data in Dickson is to show the claimed "program, " 
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then Dickson's data must be 

1) transferred to "memory, " 
and then 

2) "executed" on a "processor" in Dickson. 
That has not been shown. 

Obviousness Rejections 

No valid teaching has been given for combining the 
references. The rationale given is that a "more functional in- 
car transaction device" is obtained. (Page 6, Office Action 
mailed June 19, 2007, incorporated into Final Action on page 3, 
section 6 of latter.) 

Several problems exist in this rationale. 

Problem 1 

The phrase "more functional" has no meaning. Something 
either "functions" or it does not. The Final Action has not 
explained how degrees of "function" can exist, or how one 
compares those degrees. 

By analogy, the term is like the term "pregnant." Nobody is 
"more" pregnant than someone else. 

If a statement has no meaning, then it cannot be verified. 
Non-verifiable statements cannot act as a rationale for combining 
references . 
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Problem 2 

If the phrase means that the combined references have "more" 
"functions" than something else, then additional issues arise. 

ISSUE 1 

Those functions have not been identified. The rationale is 
a naked conclusion, unsupported by evidence. 

Further, until the functions are identified, the truth or 
falsity of the statement cannot be verified. 

ISSUE 2 

The Final Action has shown no logical connection between (1) 
the pursuit of "more functions" and (2) the claimed invention. 
That is, by what mechanism does the pursuit of "more functions" 
actually lead to the claimed invention ? 

ISSUE 3 

It appears that the rationale is actually false. When the 
in-car device of Dickson is substituted into the other reference 
(DeVries) , the other reference is then restricted to using 
stationary terminals of the Dickson- type, that is, terminals 
which transfer Dickson ! s menu-data. 

Previously, the in-car devices in DeVries could use more 
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terminals than that . 

Thus, the number of places where DeVries can now make 
purchases is reduced. That is a reduction in number of 
" functions . " 



ISSUE 4 

This rationale has not been shown in the prior art. MPEP § 
706.02 (j) states: 



Contents of a 35 U.S.C. 103 Rejection 



To establish a prima facie case of 
obviousness, three basic criteria must be 
met . 

First, there must be some suggestion or 
motivation, either in the references 
themselves or in the knowledge generally- 
available to one of ordinary skill in the 

art, to modify the reference or to combine 
reference teachings . 



The teaching or suggestion to make the 
claimed combination . . . must ... be found 
in the prior art and not based on applicant's 
disclosure . 



Problem 3 

Assuming that "more functional" has meaning, the rationale 
is not a teaching under section 103. The rationale merely points 
out a characteristic of the combination of references, but after 

14 



09/780, 696 
Art Unit 3624 
Docket no. 8771.00 



combining them. 

That is not a teaching for making the combination in the 
first place. 

Further, the mere presence of a characteristic in a 
combination of references cannot act as a teaching under section 
103. One reason is that every combination has some 
characteristics or other. If the presence of a characteristic 
acts as a teaching, then every invention would be obvious, 
because every invention is composed of individual elements which 
are found in the prior art . 

Comment 

Not all points in this Summary are elaborated below. Some 

are considered self-explanatory. 

END SUMMARY 
********** 

ARGUMENT IN FULL 

RESPONSE TO ANTICIPATION REJECTIONS OF CLAIMS 

1 - 3, 8, 10, AND 27 

Claims 1 - 3, 8, 10, and 27 were rejected on grounds of 

anticipation, based on Dickson. 

Claim 1 

Claim 1 recites, in part: 



15 



09/780, 696 
Art Unit 3624 
Docket no. 8771.00 



locating the vehicle adjacent a 
transaction terminal; 

transferring one or more computer 
programs from the transaction terminal to an 
in-car data entry facility maintained within 
the vehicle, which programs generate a user 
interface in the entry facility. 

To repeat, the claim states that 

"programs" are transferred to the "data 
entry facility" "within the vehicle, " and 

the "programs generate a user interface 
in the entry facility. " 
No such "programs," which "generate a user interface," are 
found in Dickson. 

Dickson Reference 
Dickson shows a drive-in convenience store, wherein vehicles 
enter and the driver- customers can make purchases, using an IVC, 
In-Vehicle Controller. (Column 6, lines 5 - 10; column 2, line 
2.) 

PTO's Application of Dickson 
The Office Action cites Dickson passages at, column 18, 
lines 15 - 17 and lines 28-40, as showing the claimed transfer 
of programs . . 
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These passages, and nearby passages, refer to the IVC, and 
state that 

"menu information" is transferred to the 
IVC, and 

the IVC may retain the "menu information" 
for future transactions at the convenience 
store (thereby eliminating the requirement of 
another transfer) . 

POINT 1 

Dickson states that "menu information," that is, data, is 
transferred to the IVC. 

In contrast, the claim recites "programs" which "generate 
user interface . " 

The data of Dickson does not correspond to the claimed 
"programs . " 

By analogy, the PTO is confusing 

a word-processing program 

with 

a word processing document, 
which the program would generate, display, and print. The 
program has completely different properties than does the 
document . 

A program runs on a microprocessor. The program's content 



09/780, 696 
Art Unit 3624 
Docket no. 8771.00 



namely, the instructions, must conform to the rules of syntax and 
programming established by the designer of the microprocessor. 

Such stringent requirements do not apply to data, such as a 
word processor document. In fact, a word processor document can 
be pure gibberish, which makes no sense at all, and yet be 
accepted by the word processor program. 

POINT 2 

As stated above, Dickson's IVC may retain the menu data for 
later use. Dickson states that, when the customer returns at a 
later time, that retained data is updated by new data, if 
necessary, for example, when prices change. (Column 18, lines 33 
- 36.) 

Clearly, this updating shows that Dickson transfers data, 
not a "program" as claimed. The updating transfers new 
information, that is, new data. 

POINT 3 

If Dickson were to transfer a "program, " Dickson would need 
to *know the type of microprocessor running in the IVC being used 
by the customer. The reason is that different microprocessors 
utilize different instruction sets, so that a program written for 
one microprocessor will not run on another microprocessor. 

As a specific example, Apple computers using microprocessors 
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manufactured by Motorola (or equivalent) cannot run programs 
written for IBM PCs, which use microprocessors manufactured by 
Intel (or equivalent) . 

The undersigned attorney can find no discussion in Dickson 
wherein he states that he identifies the type of IVC used by the 
customer . 

Therefore, it is reasonable to conclude that Dickson does 
not transfer a "program" as claimed. He transfers data. 

POINT 4 

Dickson states, and implies, that literally hundreds of 
different types of IVCs can be used. (Column 7, lines 43 - 55.) 
Thus, hundreds of different types of microprocessors can be 
expected . 

In order for Dickson to be operative to transfer "programs," 
as claimed, he must, as a minimum, 

identify each type of microprocessor, 
maintain a program for each type of 
microprocessor , 

select the appropriate program, based on 
the identification, and 

transfer the selected program. 
The undersigned attorney can find a discussion of none of 
this in Dickson. 
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Thus, Dickson is non-enabling for the process of 
transferring a program to the IVC, which program generates a user 
interface . 

For a reference to be anticipatory under section 102, the 
reference must be enabling. (See Patents by D. Chisum, sections 
3.06(1) (a) and 304(1). Copies were attached to Appellant's 
previous amendment . ) 

Since Dickson is non- enabling on the process of transferring 
programs to the IVCs, Dickson cannot anticipate. 

POINT 5 

As stated above, Dickson states that he updates the retained 
menu-data, as when prices change. 

If that retained data were a "program, " as claimed, then the 
updating requires at least two steps: 

1) later transferring an update for the 
program and 

2) incorporating the update into the 
retained program. 

There is no enablement in Dickson for this two-step process. 

In general, the process of modifying a computer program is 
very complex, and it is doubtful that Dickson performs it. In 
any case, he does not discuss it. 

Further, he would have to maintain a collection of update- 
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programs, one for each of the hundreds of microprocessors 
discussed above. He does not discuss that, and does not show 
enablement for that . 

Therefore, if Dickson 1 s updates (column 18, line 35) are 
interpreted as updates to computer programs, Dickson is non- 
enabling for such an interpretation. 

If he is non-enabling, he cannot anticipate. 

POINT 6 

Dickson states that his IVC is integrated with the on-board 
computer system of the vehicle, which controls engine functions. 
(Column 11, lines 19 - 21.) 

It is unreasonable to assume that a "program" is downloaded 
into the IVC, as the Final Action asserts, because of the self- 
evident possibility of infecting the vehicle's computer with a 
virus . 

The financial liability of the operator of Dickson's system 
would be enormous, if a downloaded "program" caused a malfunction 
in the automobile to which the download occurred. 

It is unreasonable to interpret Dickson as downloading a 
"program," rather than the data which he mentions. 

POINT 7 

The "interface" of the IVC is already present in the vehicle 
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of Dickson. That is, the software and hardware necessary for the 
customer to purchase gasoline, without the download of the "data" 
upon which the Final Action relies, is already present in the 
vehicle. (Column 9, line 31 - column 10, line 31; column 11, 
lines 9-18; column 11, lines 20 - 22.) 

Consistent with this conclusion (that the necessary program 
is already present in Dickson's IVC) , the "data" upon which the 
Final Action relies is that represented by block 502 in Dickson's 
Figure 11A. However, that Figure represents a flow chart of a 
computer program, already present in the vehicle, which is 
executed by equipment already present in the vehicle. 

The "data" of block 502 is received by that program. 

The "data" is not a "program." 

POINT 8 

It appears that Dickson transfers data to his IVC, but 
without any involvement of the IVC's microprocessor. If so, then 
the data cannot be a "program, " because a "program" must run on a 
microprocessor . 

Appellant submits that what probably happens in Dickson is 
the following. 
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What Happens in Dickson 
BACKGROUND 

A display in a computer contains pixels. For example, a 480 
x 640 display contains over 300,000 pixels. Assume a monochrome 
display, wherein each pixel is either white or black. 

The display is controlled by a section of memory which is 
called "video RAM," and other names such as "frame buffer." The 
video RAM contains a memory location for each pixel. A video 
driver, or "graphics card" reads the video RAM, and handles the 
details of actuating each pixel in the display. 

In this example, if a pixel is to be white, the 
corresponding memory location will be loaded with a logical ONE. 
That is, a single bit of value "1" is loaded. Conversely, if the 
pixel is to be black, a logical ZERO is loaded. 

If the price of hamburgers (such as "$ 1.00") is assigned a 
specific location on the display, then the appropriate bits in 
video RAM are loaded with the proper data, to represent "$ 1.00". 
This is illustrated graphically in the following picture, wherein 
each square represents a pixel, and also a memory location in 
video RAM. 
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WHAT DICKSON DOES 

Dickson accepts the menu-data, and loads it into the video 
RAM. This can be handled by a DMA (Direct Memory Access) device. 
From there, the graphics card handles generation of the price of 
hamburgers on the display. 

If this occurs in Dickson, then the processor is not 
involved. The data which is transferred does not "run" on the 
computer, and thus is not a "program." 

The Final Action must show that the data "runs" on the 
processor in Dickson, and that has not been done. 

Response to Final Action 
The Final Action now admits that a "program" is not 
downloaded in Dickson, but "data" is. However, the Final Action 
now asserts that the definition of "program" should be expanded, 
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to cover the data which Dickson downloads. 

The Final Action, page 5, first paragraph, states: 

The data which is transmitted to the IVC in 
Dickson instructs the device as to what 
should be displayed on the interface, and is 
considered by the Examiner to be a program. 

(Emphasis supplied.) 

Appellant points out that several problems exist in this 
assertion . 

PROBLEM 1 

The Final Action re-words a correct statement into an 
incorrect statement, to give the appearance that a "program" is 
transferred in Dickson. 

The incorrect statement is this: 

The data which . . . instructs the device as 
to what should be displayed ... is 
considered . . . to be a program. 

However, the statement is incorrect because no data 
"instructs the device." 

The data in question is simply input data to the program (s) 
which are running on Dickson's IVC. Once that revelation is 
uncovered, the error becomes clear. The Final Action is actually 
asserting something like this: 
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The input data given to Dickson's program in 
the IVC is considered to be a program, 
because the input data influences how a 
display is generated. 

The Final Action re-words this correct statement into an 
incorrect statement which is intended to give the impression that 
a "program" is transferred. 

But input data is not a program. It is data. 

To repeat: the input data in Dickson is delivered to a 
computer/program combination. That computer/program combination 
inserts the input data onto a display. 

PROBLEM 2 

The input data in Dickson is clearly information which is 
found on a restaurant menu. (Column 18, line 15 et seq.) The 
data specifies 

the price of hamburgers, 
the price of milk shakes, 

etc . 

Plainly, the computer /program combination which receives the 
data inserts that data into a larger display- image, which the 
computer /program generates on a screen. 

This conclusion is supported by the common- sense fact that 
the owner of the convenience market in which Dickson's invention 
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is installed will not be given the task of programming a 
computer, to generate screen displays. The owner only supplies 
simple items of data, which the computer/program combination 
accepts, and incorporates into the display. 

Therefore, the data in Dickson only determines a small part 
of the overall display. Thus, it is incorrect for the Final 
Action to assert that "The data . . . instructs the device as to 
what should be displayed." 

In fact, the "data" only influences a small part of what is 
displayed. And it does that by acting as input to a program 
running in the IVC, namely, that program flow-charted in 
Dickson's Figure 11A. 

PROBLEM 3 

Even if the Final Action's statement be correct (contrary to 
Appellant's assertions in PROBLEMS ! and 2), the claim recitation 
is still not shown by Dickson. 

The claim does not recite "instructing" what is displayed in 
Dickson. 

The claim recitation is this: 

. . . transferring one or more computer 
programs . . . which . . . generate a user 
interface in the entry facility . . . 

That is, the transferred "programs generate a user interface 
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in the entry facility." The "facility" is located in the 
vehicle . 

The Final Action asserts that the "data" in Dickson 
"instructs the device as to what should be displayed on the 
interface . " 

However, the claim does not recite that. The claim states 
that the "programs" transferred "generate a user interface." 
Appellant repeats : 

The Final Action asserts that Dickson's 
data determines ("instructs") what should be 
displayed. 

The claim states that the "programs" 
transferred "generate a user interface." 
Transferring data which determines/instructs what is 
displayed, as in Dickson, does not show "programs" which 
"generate a user interface," as claimed. 

PROBLEM 4 

The Final Action pre-supposes that, in Dickson, an 
"interface" is already present in the IVC, within the vehicle. 
The Final Action expressly states that the "data" determines what 
is to be displayed on that "interface." The "interface" is 
already there. 

But the claim states that the transferred "programs" 
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"generate a user interface." 

How can Dickson "generate a user interface" when the 
"interface" is already present ? 

PROBLEM 5 

The Final Action re-defines the word "program." It defines 
"program" as something that "instructs" a "device as to what 
should be displayed." 

In essence, the Final Action is asserting that anything that 
causes something to be displayed on a "device" is a "program. " 
That means that almost everything is a "program." The following 
examples illustrate this conclusion. 

Under this definition, input from a computer keyboard is a 
"program." The input controls what is displayed on a video 
screen . 

Under this definition, a music CD is a "program, " when 
played in Microsoft Windows Media Player (MWMP) . The reason is 
that MWMP displays a kaleidoscopic light -show when a song is 
playing. Thus, under the Final Action's assertion, the music CD 
is a "program. " 

Under this definition, a television signal is a "program." 
It creates images on a television screen. 

Under this definition, a speedometer cable in an automobile 
is a "program," because it "instructs" the needle on the 
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dashboard what to display. 

Under this definition, a thermocouple in an electronic 
thermometer is a "program, " because it "instructs" the numerical 
read-out "what to display." 

Under this definition, data on a telephone line which feeds 
a "caller ID" display is a program, because the data causes a 
caller's telephone number to be displayed. 

And so on. 

Appellant submits that the Final Action 1 s definition is 
completely erroneous. The mere fact that something "instructs" 
something else as to what to "display" does not make that 
"something" a "program." 

This is particularly so in Dickson because the "something" 
in question is data which is fed to a pre-existing program in his 
IVC. THAT program determines what is displayed. 

PROBLEM 6 

In concluding that Dickson shows the claimed "program, " the 
Final Action fails to comply with the MPEP. 
MPEP § 2164.04 states: 

For terms that . . . could have more than one 
meaning, it is necessary that the examiner 

select the definition that he/she 
intends to use when examining the 
application, based on his/her 
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understanding of what applicant 
intends it to mean, 

and 

explicitly set forth the meaning of 
the term and the scope of the claim 
when writing an Office action. 

The Final Action has not followed this MPEP section. The 
Final Action has not set forth "the meaning of the term" 
"program", as required. 

Instead, the Final Action has merely asserted the 
unsupported conclusion that the data in Dickson qualifies as a 
"program. " 

PROBLEM 7 

The Final Action, page 5, states "Programs may be anything 
which instruct a computer." However, no support for this 
assertion has been given. Support is required. 

Support is required for the simple reason that the statement 
is so broad as to be plainly incorrect. The undersigned attorney 
owns a laptop computer, which has a cordless, infra-red (IR) 
mouse. Movement of the mouse causes IR signals to be sent to the 
computer, causing a cursor to move on the display. "Clicking" a 
mouse button causes other IR signals to be sent, causing other 
actions . 

Under the Final Action's view, these IR signals are 
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"programs, " because they "instruct a computer." 

That view is not orthodox, and cannot be accepted without a 
citation of authority. 

Similarly, speech recognition programs exist, which accept 
spoken words as input, and cause a. computer to respond according 
to the spoken words, or to print the words which are "heard" by 
the program. Under the Final Action's view, these spoken words 
are "programs." That view is, again, heterodox. 

Conclusion 

No "program" is transferred as recited in claim 1. The item 
in Dickson relied on to show the claimed "program" is the data of 
block 502 in his Figure 11A. 

That data is INPUT to a program in Dickson's IVC. 

Input is not a "program." It is input data. 

Other Claims 

The discussion above applies to the other claims in this 
group . 

Claim 27 
POINT 1 

Claim 27, and its parent claim 1, state that the vehicle is 
positioned at first and second terminals (at different times, of 
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course) . 

The Final Action has not shown that Dickson states that a 
given IVC can be used at two different terminals. 

POINT 2 

Under claim 27, first programs are transferred at the first 
terminal, and second programs are transferred at the second 
terminal. This operation has not been shown in Dickson. 



As explained herein, Dickson sometimes, and perhaps most of 
the time, stores menu-data in the IVC, and does not transfer it 
when the IVC returns to a terminal. Thus, even assuming that 
Dickson shows the items in Point 2, above, the following 
possibilities exist : 



In these possibilities, items (1) and (3) must be shown in 
Dickson, to show the claim. That has not been done. 



POINT 3 



1) 
2) 
3) 
4) 



IVC visits 1st terminal 

IVC visits 1st terminal 

IVC visits 2nd terminal 

IVC visits 2nd terminal 



Transfer occurs 
No transfer 
Transfer occurs 
No transfer 



POINT 4 

The claim states that the second interface is different from 
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the first. The Final Action, page 3, asserts that this is 
"inherent" in Dickson. 

MPEP § 2112 states: 

EXAMINER MUST PROVIDE RATIONALE OR EVIDENCE 
TENDING TO SHOW INHERENCY. 

In relying upon the theory of inherency, the 
examiner must provide a basis in fact and/or 
technical reasoning to reasonably support the 
determination that the allegedly inherent 
characteristic necessarily flows from the 
teaching of the applied prior art. 

No "basis in fact and/or technical reasoning" has been 
provided, as required by this MPEP section. 

Appellant points out that, in Dickson, the same IVC would be 
used at both terminals. The same program will be present in that 
IVC at both locations. If new menu-data is loaded into the IVC 
at the second terminal (which has not been shown) , then the only 
difference wilL be that of menu-prices displayed. 

That difference (which has not been shown) does not 
necessarily mean that the "a second user interface" is "different 
from said [first] interface." 

Appellant points out that, under the claim, the "interfaces" 
are generated by the "programs" which are transferred. The claim 
states that "first" and "second" programs are transferred. 

"Programs" are not transferred in Dickson, which generate 
the interfaces. Thus, any differences are not due to "programs." 
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Claim 8 

The discussion of claim 1 applies to claim 8. 
In addition, claim 8 recites: 



. . . means for receiving a computer program 
from the transaction terminal which generates 
an interface in the apparatus . . . 



This is a n means-plus-f unction" phrase. Section 112 states: 

An element in a claim for a combination may 
be expressed as a means . . . for performing 
a specified function . . . 

and 

such claim shall be construed to cover the 
corresponding structure, material, or acts 
described in the specification and 
equivalents thereof . 



POINT 1 

The Specification discusses items which "correspond" to the 
claim, on page 7, lines 8-10: 



A series of computer programs are then 
transferred from the terminal 32 to the 
memory 24 . . . , where processor 22 executes 
the programs to generate an appropriate 
interface environment for the particular 
transaction type. 



The Final Action relies on the data of Dickson's block 502 
in his Figure 11A to show the claimed "program." 
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If that data qualifies as the claimed "program, " then the 
data must "run" on a processor, in order to "correspond" with 
Appellant ' s Specification. 

However, in Dickson, nothing which "runs" the data, to 
generate "an interface in the apparatus" has been shown. 

Nor has an "equivalent" been shown. 



POINT 2 

As explained above, Dickson states that his menu-data is not 
transferred for every transaction. It can be saved by the IVC 
for a later transaction. (Column 18, lines 28 - 36.) 

That does not correspond to Appellant's Specification. 

RESPONSE TO OBVIOUSNESS REJECTIONS 
CLAIMS 21-25 

Claims 21 - 25 were rejected as obvious, based on Dickson 
and DeVries. 

Claim 21 

Point 1 

No valid teaching has been given for combining the 
references . 

The rationale given is that the combined references provide 
a "more functional in-car transaction device." 
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However, this rationale, in essence, asserts that certain 
properties of the combination of references are desirable, and 
thus the references should be combined for that reason. 

However, that is not a teaching for combining the references 
in the first place. That merely points to supposed properties of 
the references, once combined. 

If this type of rationale suffices as a teaching under 
section 103, then almost all, and possibly all, inventions ever 
made would be obvious. The reason is that all inventions have 
some properties or other which are considered desirable. 

Therefore, the mere presence of desirable properties in the 
combination of references is not a basis for rejection under 
section 103 . 

Point 2 

Appellant submits that the rationale is a meaningless 
statement, and thus cannot be used. 

Something either "functions" or it does not. The Final 
Action has not explained how degrees of "function" exist, so that 
something can be "more functional" than another thing. 

It could be that "more functional" means that more 
"functions" are provided by the combined references. 

If so, where is the teaching in the prior 
art that this is desirable ? 
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If so, Appellant is entitled to request 
that those functions be identified, so that 
he can verify whether, in fact, "more" 
"functions" are attained. Until the 
functions are identified, the rationale is 
merely an unjustified conclusion. 

If so, -then the Final Action is combining 
references, merely for the sake of combining 
them. That is, in essence, the reason for 
the combination is to add the "functions" of 
one reference to another, to attain a "more 
functional" device. That is not the standard 
for a teaching of obviousness. 



Point 3 

The MPEP requires that the teaching be found in the prior 
art. MPEP § 706.02 (j) states: 

Contents of a 35 U.S.C. 103 Rejection 



To establish a prima facie case of 
obviousness, three basic criteria must be 
met . 

First, there must be some suggestion or 
motivation, either in the references 
themselves or in the knowledge generally 
available to one of ordinary skill in the 
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art, to modify the reference or to combine 
reference teachings . 



The teaching or suggestion to make the 
claimed combination . . . must • . • be found 
in the prior art and not based on applicant's 
disclosure . 

But the rationale points to properties of the combined 
references as a justification for combining the references. 

That is, the references are combined in order to obtain 
those properties. 

But those properties have not been identified in the prior 
art. The PTO has not shown its justification in the prior art, 
as required. 

Point 4 

The Final Action, page 6, asserts that one in possession of 
Dickson would look to similar references for features to add to 
Dickson. 

Appellant points out that this is not the test of 
obviousness . 

One does not equip the hypothetical person skilled-in- the- 
art with a reference, and then commission that person to improve 
the reference. 
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Point 5 

The Final Action relies on the KSR decision. Appellant 
points out that, under the rules of precedent, the KSR decision 
is limited to its facts (as are all court decisions) . 

In KSR, the references contained all teachings needed to 
produce the claimed invention. Nothing was needed from the 
Examiner . 

Specifically: in KSR, claim 4 was in issue. The Court held 
that all elements of claim 4 were taught in a single reference 
(Asano) , with one exception. That exception was a sensor, which 
sensed position of a movable pedal, but which itself was fixed in 
position. (550 U.S. at 7, 18.) 

However, a Smith patent taught that the sensor should be 
stationary, to avoid chafing of wires attached to a sensor which 
moved. (550 U.S. at 4 . ) 

The court held that everything needed to produce claim 4 was 
found in Asano and Smith. (550 U.S. at 18.) 

No additional teachings were required. 

That is different from Appellant's situation. The 
motivation for combining the references are not found in the 
references themselves. The motivation was provided by the 
Examiner . 
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Point 6 

KSR is limited to a situation involving "a patent claiming 
the combination of elements of prior art ..." (550 U.S. at 13, 
last full paragraph.) 

This is not trivial: the "elements" "combined" must be found 
in the prior art . 

In Appellant's situation, as explained above, the element of 
downloading a "program" which generates an "interface" has not 
been shown in the prior art . 

The Final Action is not combining elements found in the 
prior art. KSR is distinguishable on its facts. 

Point 7 

The Final Action cites KSR for the proposition that a 
"specific teaching" is not required. That is not correct. 
The court in KSR stated: 

Often, it will be necessary for a court to 
look to 

interrelated teachings of multiple 
patents ; 

the effects of demands known to the 
design community or present in the 
marketplace; and 

the background knowledge possessed by a 
person having ordinary skill in the art, 

all in order to determine whether there was 
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an apparent reason to combine the known 
elements in the fashion claimed by the patent 
at issue. 

To facilitate review, this analysis should be 
made explicit. 



" [R] ejections on obviousness grounds cannot 
be sustained by mere conclusory statements; 
instead, there must be some articulated 
reasoning with some rational underpinning to 
support the legal conclusion of obviousness." 
[Citation.] 

The court then stated that "precise teachings directed to 
the specific subject matter of the challenged claim" need not be 
found in the references. 

But teachings are still required. They can be found in the 
"inferences and creative steps that a person of ordinary skill in 
the art would employ." (550 U.S. at 14, end of first paragraph.) 

In essence, the Final Action is asserting that its rationale 
that the combination of references is "more functional" than 
something else qualifies as the "inferences and creative steps . 
. ." of KSR. But that rationale is the Final Action f s 
fabrication . 

It has not been shown in the prior art. 
No evidence has been given that the 
"skilled person" believes in that rationale. 
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Point 8 

The combination of references renders DeVries inoperative. 
MPEP § 2143.01, section 5, states: 

The proposed modification cannot render the 
prior art unsatisfactory for its intended 
purpose . 

DeVries shows a device in a vehicle which allows the driver 
to make purchases. He states that his system is usable at 
numerous types of locations, including "drive- through fast food 
sales, " and "drive- through bank transactions, and the like." 
(Column 2, lines 2 - 4.) 

Under the combination of references, "data" must now be 
downloaded into the device of Dickson, which was substituted into 
DeVries. However, now the transactions of DeVries cannot occur, 
because the locations where the transactions occur do not have a 
facility for downloading the "data" into the device of Dickson. 

The combination is inoperative, and the mode of operation of 
DeVries has been altered. 

Point 9 

As explained above, Dickson does not transfer the menu-data 
every time. Sometimes he does not. And it is possible that most 
of the time he does not . 

Thus, two operations are present in Dickson: 
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1) a customer purchase without menu-data 
transfer 

and 

2) a customer purchase with menu-data 
transfer . 

The Final Action is combining one of these operations (item 
(2)) with the other reference. 

But no teaching has been given for selecting that operation, 
to the exclusion of the other operation. 

A teaching is required for selecting an item in a reference, 
and combining the selected item with another reference. 

Point 10 

The references are contradictory, as explained in Point 2, 
below, in connection with claim 22. 

Conclusion 

Appellant thus submits that the rejection of claim 21 cannot 
stand. 

Claim 22 

The discussion of parent claim 21 applies here. 
ALso, claim 22 recites transfer of a computer program to a 
device in a vehicle. The Office Action asserts that Dickson 
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shows the claimed transfer of computer programs. 

Point 1 

Applicant believes that the discussion above indicates that 
the claimed transfer of computer programs is not shown in 
Dickson. Thus, even if the references are combined, the claimed 
transfer of programs is not found. MPEP § 2143.03 states: 

To establish prima facie obviousness . . . 
all the claim limitations must be taught or 
suggested by the prior art . 

Point 2 

The references are contradictory. 

DeVries discusses an interface in the device which is 
mounted in his vehicle. It is clear that (1) no programs are 
transferred to that interface, and (2) the interface requires no 
transfer of programs. (See column 5, lint 57 et seq.; column 9, 
liner 15 et seq . ) 

Thus, DeVries teaches away from the concept of transferring 
programs to the device within the vehicle, and thus contradicts 
the supposed teaching of program- transfer found in Dickson. 

Claims 23 and 24 

Claims 23 and 24 are considered patentable, based on their 
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parent claims. 



Claim 25 

Point 1 

Claim 25 is "consisting essentially of 11 type (as opposed to 
"comprising 11 type) . The Final Action, page 6, asserts that the 
transitional phrase "consisting essentially of" can be ignored. 
However, several problems exist in this assertion. 



PROBLEM 1 

The PPG decision, cited by the Office Action, states: 

By using the term "consisting essentially 
of, 11 the drafter signals that the invention 
necessarily includes the listed ingredients 
and is open to unlisted ingredients that do 
not materially affect the basic and novel 
properties of the invention. 

A "consisting essentially of" claim occupies 
a middle ground between ["consisting" and 
"comprising" claims] . 

(CAFC opinion 97-1513, section II, first 
paragraph. ) 

The Final Action is not following the opinion. The Final 
Action refuses to acknowledge the "middle ground" set forth in 
the option. Instead, the Final Action invokes the "comprising" 
extreme, which is only one border of the "middle ground." 
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PROBLEM 2 

The Final Action has not actually shown a system which is 
produced by the combination of references. The Final Action has 
only asserted that individual claim elements are found in the two 
references . 

Thus, it cannot be determined whether any non-claimed 
material in that system lies outside the "consisting essentially 
of" limitations, which are explained in Problem 3, below. 



Problem 3 

In a "consisting essentially of" claim, the question is 
whether the non-claimed elements, in the subject matter to which 
the claim is compared, have a "material effect on the basic and 
novel characteristics" of the claimed . invention. 

The PPG decision, cited by the Final Action, states: 



The jury was instructed that "consisting 
essentially of" means that the claimed . . . 
invention has in it the ingredients that are 
specifically identified in the claim. 
... 

Other ingredients may also be present in the 
glass, although not specifically identified 
in the claim, so long as those other unlisted 
ingredients do not have a material effect on 
the basic and novel characteristics of the 
glass . 

(CAFC opinion 97-1513, section II, second 
paragraph. ) 
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The CAFC held that the jury instruction was correct. It 
stated : 

The [district] court properly left it to the 
jury to determine whether the amounts of iron 
sulfide in [the infringing] glass have a 
material effect on the basic and novel 
characteristics of the glass. 

(CAFC opinion 97-1513, section II, last 
paragraph. ) 

Therefore, the question is whether the combined references 
contain elements which "have a material effect on the basic and 
novel characteristics of" the claimed invention. 

What are the 1 basic and novel characteristics' of the 
claimed invention ? 

As discussed above, the claimed ATM transfers programs to an 
in- vehicle device, which programs generate an interface. 

Appellant's Specification refers to an ATM, Automated Teller 
Machine, at page 1, lines 5 and 9. The Specification repeatedly 
refers to a terminal which dispenses cash, such as an ATM: 
page 3, lines 24 and 27; 
page 4, line 21; 

page 6, line 26, which refers to a media 
dispenser 38 in Figure 2, which is a generic 
cash dispenser; 
page 7, line 18; and 
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original claim 4. 
Plainly, the "basic and novel characteristics 11 of claim 25 
include an ATM which dispenses cash, and transfers the programs 
recited above. 

These "characteristics" do not include the gas station, nor 
the convenience store, of Dickson. 

The combined references contain numerous elements which are 
outside those recited in the claim, and which alter the "basic 
and novel characteristics" of the invention. 

Requiring an ATM customer to visit a gas 
station alters the invention. 

Requiring an ATM customer to visit a 
convenience store alters the invention. 

Requiring an ATM customer to receive 
downloaded menu-data, which states the price 
of hamburgers, alters the invention. 

Point 2 

Claim 25(d) and (e) recite "prompts" which are issued by the 
" interface . " 

The Final Action admits that the "prompts" are not found in 
the combined references. (Page 4, second paragraph.) 

The Final Action relies on Official Notice to show the 
"prompts . " 
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However, the Noticed subject matter does not show the 
claimed "prompts." The - Noticed subject matter is that an ATM 
issues the "prompts." The claim does not state this. The claim 
states that the in-car "interface" issues the "prompts." 

Restated: the Noticed "prompts" are displayed on a video 
screen which is fastened to an ATM. The claim states that the 
in-car "interface" issues the "prompts." 

The claimed "prompts" appear IN THE VEHICLE, not on an ATM 
external to the vehicle. 

Further, the Notice is contrary to claim 25(f), which states 
that the data input, in response to the "prompts," is "relayed" 
to the ATM. Under the Noticed subject matter, there is no need 
for such a "relay." Under the Noticed subject matter, the ATM 
receives the data directly. 

Point 3 

No valid teaching has been given for combining the Noticed 
subject matter with the other two references. 

The rationale given simply sets forth the effects which the 
Noticed "prompts" have in an ATM. That does not lead to a 
combination of the references. If you want those effects, then 
simply use the Noticed ATM. There is no reason to combine the 
references to attain those effects. 

In addition, as explained above, even if the Noticed ATM is 
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combined with the other references, the "prompts" of claim 25(d) 
and (e) are not attained. 



Point 4 

It appears that the Final Action is making an incorrect 
rejection. DeVries discusses a "cash" "machine" of a "bank." 
(Column 5, lines 40 - 41.) 

The Final Action perhaps should be asserting that this 
"machine" inherently shows the prompts. 

Appellant thus points to MPEP § 2112, which states: 



EXAMINER MUST PROVIDE RATIONALE OR EVIDENCE 
TENDING TO SHOW INHERENCY. 

In relying upon the theory of inherency, the 
examiner must provide a basis in fact and/or 
technical reasoning to reasonably support the 
determination that the allegedly inherent 
characteristic necessarily flows from the 
teaching of the applied prior art. 



RESPONSE TO OBVIOUSNESS REJECTIONS 

CLAIMS 4-6 

These claims are considered patentable, based on their 
parent claims. 
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CONCLUSION 



Appellant requests that the Board reverse the rejections, 
and pass all claims to issue. 



NCR Corporation 

1700 South Patterson Blvd. 

WHQ - 3 

Dayton, OH 45479 
February 27, 2008 
(937) 445 - 4956 



ATTACHMENTS: -- CLAIMS APPENDIX, 



-- STATEMENT THAT NO EVIDENCE APPENDIX IS 

ATTACHED, 

and 

-- STATEMENT THAT NO RELATED PROCEEDINGS APPENDIX 
IS ATTACHED 



Respectfully submitted, 




Reg. No. 3 0,434 
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8. CLAIMS APPENDIX 

1. A method of conducting a transaction from within a 
vehicle, the method comprising the steps of: 

locating the vehicle adjacent a transaction terminal; 

transferring one or more computer programs from the 
transaction terminal to an in-car data entry facility maintained 
within the vehicle, which programs generate a user interface in 
the entry facility; 

entering user instructions into the in-car data entry 
facility; and 

transmitting the user instructions locally to the 
terminal for execution by the terminal. 

2. A method in accordance with claim 1, further comprising 
the step of identifying the user. 

3. A method in accordance with claim 1, further including 
the steps of transmitting data locally from the terminal to the 
vehicle, and displaying a part of the data on an in-car display 
located within the vehicle. 

4. A method in accordance with claim 1, further comprising 
the step of retrieving cash or other valuable media dispensed 
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from the terminal . 

'5. A method in accordance with claim 1, further comprising 
the step of uploading electronic valuable media to a memory 
storage device located within the vehicle. 

6. A method in accordance with claim 1, further comprising 
the step of downloading electronic valuable media to the terminal 
from a memory storage device. 

8. An in-car apparatus to be provided within a vehicle for 
user interfacing with a transaction terminal, the apparatus 
comprising : 

. means for interacting with a user; 

means for receiving a computer program from the 

transaction terminal which generates an interface in 

the apparatus; and 

means for transmitting data locally to a transaction 
terminal situated adjacent the apparatus. 

10. An apparatus in accordance with claim 8, further 
comprising memory storage means for recording data. 

21. A method, comprising: 
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a) maintaining a wireless communication device within 
a vehicle; 

b) positioning the vehicle near an Automated Teller 
Machine, ATM; 

c) establishing wireless communication between the 
wireless device and the ATM; 

d) entering identification data into the wireless 
device, which data allows the ATM to verify identity of 

- a user; and 

e) if the' ATM verifies the user, proceeding with a 
financial transaction . 

22. Method according to claim 21, and further comprising 

f) transferring one or more computer programs from the 
ATM to the device, which programs generate an interface 
for the user. 

23. Method according to claim 21, wherein the 
identification data is obtained from a card presented to the 
device . 

24. Method according to claim 21, wherein the 
identification data is obtained from a keypad operated by the 
user . 
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25. A method, comprising consisting essentially of the 
steps of : 

* a) maintaining a wireless communication device within 
a vehicle, said device comprising a keypad and a card 
reader; 

b) positioning the vehicle near an Automated Teller 
Machine, ATM; 

c) establishing wireless communication between the 
wireless device and the ATM and transferring one or 
more computer programs from the ATM to the device, 
which programs generate an interface for the user; 

d) inserting a card into the card reader in response 
to a prompt issued by the interface; 

. e) entering a PIN into the keypad in response to a 
prompt issued by the interface; 

f) relaying data from the card, and the PIN, to the 
ATM ; and 

g) if the card and the PIN are accepted by the ATM, 
proceeding with a financial transaction. 

27. Method according to claim 1, and further comprising 
locating the vehicle adjacent a second transaction 

terminal ; 
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transferring one or more second computer programs from 
the transaction terminal to an in-car data entry facility 
maintained within the vehicle, which programs generate a second 
user interface, different from said interface, in the entry 
facility; 

entering user instructions into the in-car data entry 
facility; and 

transmitting the user instructions locally to the 
terminal for execution by the terminal. 
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9. EVIDENCE APPENDIX 



None . 
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10. RELATED PROCEEDINGS APPENDIX 



None . 
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